9.2 Debuggen mit Programmcode 

9.2.1 Einführung 

In Abschnitt 9.1 haben wir uns mit Fehlern beschäftigt, die nach der erfolgreichen Kompilierung zur Laufzeit auftreten können und, falls sie nicht behandelt werden, unweigerlich zum Absturz des Programms führen. Vielleicht noch schlimmer sind Fehler, die weder vom Compiler erkannt werden, noch einen Laufzeitfehler verursachen. Es sind die logischen Fehler, die ein falsches oder zumindest unerwartetes Ergebnis zur Folge haben. Um logische Fehler aufzuspüren, muss die Anwendung unter Zuhilfenahme des integrierten Debuggers untersucht werden.

Das .NET Framework stellt Ihnen eine Reihe von Hilfsmitteln zur Verfügung, um den Programmcode zu debuggen. Die Spanne reicht von der einfachen Ausgabe von Meldungen im Ausgabe-Fenster bis zur Umleitung der Meldungen in eine Datei oder das Windows-Ereignisprotokoll. Dabei können Sie das Laufzeitverhalten einer Anwendung sowohl mit Programmcode als auch mit der Unterstützung von Visual Studio 2005 überprüfen. Wir werden in den nächsten Abschnitten auf alle Debugging-Techniken eingehen.

9.2.2 Die Klasse »Debug« 

In den vorangegangenen Beispielen haben wir uns sehr häufig eines Kommandos bedient, um beispielsweise den Inhalt von Variablen zu überprüfen. Es war die Methode WriteLine der Klasse Console:

Diese Technik hat zur Folge, dass die Ausgabe an der Konsole unübersichtlich wird und zwischen den erforderlichen Programminformationen immer wieder Informationen zu finden sind, die nur der Entwicklungsunterstützung dienen. Bevor ein solches Programm an den Kunden ausgeliefert wird, müssen die Testausgaben aus dem Programmcode gelöscht werden.

Die Entwicklungsumgebung bietet uns eine bessere Alternative an. Dazu wird die Ausgabe nicht in das Konsolenfenster geschrieben, sondern in das Ausgabe-Fenster von Visual Studio 2005. Standardmäßig wird dieses Fenster am unteren Rand der Entwicklungsumgebung angezeigt. Sie können es sich anzeigen lassen, indem Sie im Menü Ansicht den Menüpunkt Ausgabe wählen.

Hier klicken, um das Bild zu Vergrößern

Abbildung 9.3     Das Fenster »Ausgabe«

Sie haben dieses Fenster möglicherweise schon häufig gesehen und aufmerksam seinen Inhalt gelesen, denn bei jeder Kompilierung werden hier Informationen ausgegeben, beispielsweise ob die Kompilierung fehlerfrei war. Das Ausgabe-Fenster zeigt uns aber nicht nur Informationen an, die der Compiler hineinschreibt, wir können auch eigene Meldungen in dieses Fenster umleiten.

Eine Debug-Information in das Ausgabe-Fenster zu schreiben, ist genauso einfach wie die Ausgabe an der Konsole. Wir müssen nur die Anweisung

durch

ersetzen. Debug ist eine nicht ableitbare Klasse des Namespace System.Diagnostics, die ausschließlich statische Member bereitstellt.

Die Methode Debug.WriteLine unterscheidet sich von der Methode Console.WriteLine dahingehend, dass sie keine Formatierungsmöglichkeiten erlaubt. Um mehrere Informationen in einer gemeinsamen Zeichenfolge unterzubringen, müssen Sie daher den »+«-Verknüpfungsoperator benutzen:

Programmablaufinformationen anzeigen

Debug.WriteLine ist mehrfach überladen und kann ein Argument vom Typ String oder Object entgegennehmen. Eine parameterlose Überladung gibt es nicht.

Optional können wir auch ein zweites String-Argument übergeben, das eine detaillierte Beschreibung bereitstellt, die vor der eigentlichen Debug-Information ausgegeben wird.

Sehen wir uns das an einem Beispiel an. Die Anweisung

wird in das Ausgabe-Fenster

schreiben – vorausgesetzt, der Inhalt von value ist 34.

Neben WriteLine sind in der Klasse Debug noch weitere Methoden zur Ausgabe von Informationen definiert. Die Tabelle 9.2 gibt darüber Auskunft.

Die beiden zuletzt aufgeführten Methoden WriteIf und WriteLineIf schreiben nur dann Debug-Informationen, wenn eine bestimmte Randbedingung erfüllt ist. Damit lässt sich der Programmcode übersichtlicher gestalten. Beide Methoden sind genauso überladen wie Write bzw. WriteLine, erwarten jedoch im ersten Parameter zusätzlich einen booleschen Wert, z.  B.:

Verdeutlichen wir uns den Einsatz an einem Beispiel. Um den Inhalt des Feldes value zu testen, könnten wir in herkömmlicher Weise codieren:

Mit WriteLineIf wird daraus eine Codezeile:

Wie Sie später noch sehen, bieten uns die Methoden WriteLineIf und WriteIf sehr bequem einzusetzende Möglichkeiten, eine Ablaufprotokollierung zu steuern.

Einrücken der Ausgabeinformation

Die Klasse Debug stellt uns Eigenschaften und Methoden zur Verfügung, um die Debug-Ausgaben einzurücken. Mit der Methode Indent wird die Einzugsebene um eins erhöht, mit Unindent um eins verringert. Standardmäßig beschreibt eine Einzugsebene vier Leerzeichen. Mit der Eigenschaft IndentSize kann ein anderer Wert bestimmt werden. IndentLevel erlaubt, eine bestimmte Einzugsebene festlegen, ohne Indent mehrfach aufrufen zu müssen.

An einem Beispiel wollen wir uns noch die Auswirkungen ansehen.

Der Code führt zu folgender Ausgabe:

Die Methode »Assert«

Mit der Methode Assert können Sie eine Annahme prüfen, um beispielsweise unzulässige Zustände festzustellen. Die Methode zeigt eine Fehlermeldung an, wenn ein Ausdruck mit False ausgewertet wird.

Hat die Eigenschaft value einen Wert, der kleiner 0 ist, erscheint auf dem Bildschirm die in der folgenden Abbildung gezeigte Nachricht.

Hier klicken, um das Bild zu Vergrößern

Abbildung 9.4     Die Meldung der Methode »Debug.Assert«

Das Dialogfenster enthält neben der dem zweiten Parameter übergebenen Zeichenfolge auch Informationen darüber, in welcher Klasse und welcher Methode der Assertionsfehler aufgetreten ist.

9.2.3 Die Klasse »Trace« 

Die Klasse Trace unterscheidet sich in der Liste ihrer Eigenschaften und Methoden nicht von Debug. Dennoch gibt es einen Unterschied, der sich nur bei einem Wechsel der Build-Konfiguration zwischen Release und Debug bemerkbar macht (siehe Abbildung 9.5).

Hier klicken, um das Bild zu Vergrößern

Abbildung 9.5     Die Einstellung der Debug-/Release-Build-Konfiguration

Die Debug-/Release-Konfiguration

Standardmäßig ist bei jedem Projekt die Konfiguration Debug ausgewählt. Anweisungen, die auf den Klassen Debug oder Trace basieren, werden dann grundsätzlich immer bearbeitet. Wird jedoch die Konfiguration Release gewählt, ignoriert der VB-Compiler Aufrufe auf die Klasse Debug, während Aufrufe auf Trace weiterhin bearbeitet werden.

Das ist aber noch nicht das Wesentlichste. Viel wichtiger ist die Tatsache, dass Aufrufe auf Trace kompiliert werden – unabhängig davon, ob Sie die Konfiguration Debug oder Release eingestellt haben. Viele Trace-Anweisungen vergrößern deshalb auch das DLL- bzw. EXE-Kompilat. Andererseits hat der Entwickler hier auch eine einfache Möglichkeit, bestimmte Zustände, die sich zur Laufzeit einstellen und geprüft werden müssen, zu protokollieren.

Unterhalb des Verzeichnisses, in dem sich die Quellcodedateien befinden, legt die Entwicklungsumgebung das Verzeichnis \bin an, dem selbst je nach eingestellter Build-Konfiguration die beiden Verzeichnisse \Debug und \Release untergeordnet sind. Abhängig von der Konfigurationseinstellung wird das Kompilat der ausführbaren Datei in eines dieser beiden Unterverzeichnisse gespeichert.

Debug-Informationen, die beim Kompilieren generiert werden, sind in einer Datei mit der Dateierweiterung .PDB im Verzeichnis gespeichert. Der Debugger nutzt die darin enthaltenen Informationen, um Variablennamen und andere Informationen während des Debuggens in einem sinnvollen Format anzuzeigen.

9.2.4 Ablaufverfolgung mit »TraceListener«-Objekten 

Standardmäßig erfolgt die Ausgabe der Ablaufverfolgungsmeldungen im Fenster Ausgabe. Mit dem Schließen des Ausgabe-Fensters gehen auch die Meldungen verloren. Das .NET Framework stellt Ihnen aber auch Konzepte zur Verfügung, um die Meldungen beispielsweise in eine Datei oder das Ereignisprotokoll von Windows umzuleiten. Verantwortlich dafür sind Listener-Objekte.

Im Namespace System.Diagnostics sind fünf Listener vordefiniert, die alle aus der abstrakten Klasse TraceListener abgeleitet sind:

ConsoleTraceListener

DefaultTraceListener

DelimitedListTraceList

TextWriterTraceListener

EventLogTraceListener

Eine Beschreibung der genannten Klassen können Sie der Tabelle 9.3 entnehmen.

Das sind noch nicht alle vordefinierten Listener, die das .NET Framework anbietet. Die anderen lassen sich aber schwerlich in einem .NET-Grundlagenteil einbauen, deshalb soll es auch bei der kurzen Erwähnung bleiben. Wenn Ihnen danach ist, können Sie auch eigene Listener definieren. Sie brauchen dazu nur die Klasse TraceListener abzuleiten.

Die Listener-Objekte sind an die Klassen Debug und Trace gebunden. Beide Klassen stellen mit Listeners eine Eigenschaft vom Typ TraceListenerCollection bereit. Diese Auflistung weist die von einer ArrayList bekannten Eigenschaften und Methoden auf, also z.  B. Add, Remove, Clear. Beachten Sie, dass die Listener-Objekte sowohl von Trace als auch von Debug gemeinsam benutzt werden. Beide Klassen bedienen sich also derselben Auflistung.

Sehen wir uns nun an einem Beispiel an, wie die Listener eingesetzt werden.

In der ersten Anweisung wird die Listeners-Auflistung mit Clear geleert. Weil damit der standardmäßige Eintrag des DefaultTraceListeners-Objekts gelöscht wird, würde ein Debug.Write- oder Trace.Write-Methodenaufruf keinen Abnehmer mehr finden und im Nirwana verpuffen. In der folgenden Codezeile wird daher die Klasse ConsoleTraceListener instanziiert. Dieses Objekt leitet die Ausgabemeldungen an die Konsole um und wird mit der darauf folgenden Anweisung der TraceListenerCollection übergeben.

Da sich die Klassen Trace und Debug die installierten Listener gleichberechtigt teilen, werden in der Build-Konfiguration Debug beide Meldungen an der Konsole angezeigt.

Die Klasse »TextWriterTraceListener«

Eine Liste von insgesamt sieben Konstruktoren zeugt davon, dass die Klasse TextWriterTraceListener die flexibelste der Listener ist. Neben dem parameterlosen Konstruktor kann dieser Listener auch mit einem TextWriter- oder einem Stream-Objekt verbunden werden.

Nehmen wir an, dass Sie Ihre Debug-Informationen in einer Datei speichern möchten. Im einfachsten Fall brauchen Sie dem Konstruktor nur eine Zeichenfolge zu übergeben, die den Pfad zu der Datei beschreibt. Anschließend muss der neue Listener registriert werden.

TextWriterTraceListener schreibt alle Ausgabeinformationen zunächst in einen Puffer. Mit dem Aufruf der Methode Flush wird der Puffer geleert und der Inhalt in die Datei geschrieben. Alternativ dazu können Sie auch die Eigenschaft AutoFlush=True setzen. Mit Close wird das TextWriterTraceListener-Objekt geschlossen. Soll danach die Ablaufverfolgung wieder aufgenommen werden, muss der Listener neu initialisiert und registriert werden.

Die Klassen Debug und Trace bedienen sich derselben Listener. Daher werden beide Write-Anweisungen in der Datei einen Abnehmer finden – vorausgesetzt natürlich, dass die Anwendung im Debug- und nicht im Release-Modus ausgeführt wird.

Ist die Datei bereits vorhanden, werden die Debug-Informationen an den alten Dateiinhalt angehängt. Vielleicht wünschen Sie aber, dass die alten Einträge überschrieben werden. Hier hilft die Überladung des TextWriterTraceListener-Konstruktors weiter, welche die Referenz auf ein Stream-Objekt erwartet.

Im folgenden Beispiel wird dem Konstruktor eine Referenz vom Typ FileStream übergeben. Das FileStream-Objekt leitet die Ausgabe in eine Datei um. Ist die Datei bereits vorhanden, wird die alte überschrieben, ansonsten wird eine neue erzeugt. Dafür sorgt die Angabe FileMode.Create.

Sehr häufig werden Listener dazu benutzt, aufgetretene Laufzeitfehler im Catch-Zweig der Fehlerbehandlung zu protokollieren. In diesem Beispiel wird in der Methode Operation eine Exception mit einer spezifischen Fehlermeldung erzeugt. Neben der Fehlermeldung werden in der Protokolldatei auch noch Datum und Uhrzeit des Auftretens der Ausnahme festgehalten. Die entsprechende Information liefert uns die statische Methode Now der Klasse DateTime.

Mehrere Listener verwalten

Ein TextWriterTraceListener beschreibt immer genau einen Informationsabnehmer und eignet sich nicht nur dazu, Fehler zu protokollieren. Sie können einen Listener auch genauso gut dazu benutzen, allgemeine Informationen in einen Stream zu schreiben.

Es sind deshalb auch Szenarien vorstellbar, in denen mehrere Listener mit unterschiedlichen Aufgaben benötigt werden. Grundsätzlich werden Meldungen von jedem registrierten Listener gepuffert. Soll eine Meldung nur von einem bestimmter Listener verarbeitet werden, muss die Registrierung der anderen Listener zumindest zeitweise aufgehoben werden. Mit den Methoden Add, Remove sowie dem Indexer ist das grundsätzlich möglich. Allerdings ist es einfacher, ein Listenelement über einen Namen als über den Index in der Auflistung anzusprechen. Daher stellt die Klasse TextWriterTraceListener Konstruktoren mit einem zweiten Parameter bereit, um den Listener zu benennen. Der Name des Listeners wird in der Eigenschaft Name eingetragen.

Im folgenden Beispiel werden zwei Listener registriert und beiden eine Zeichenfolge übergeben. Anschließend wird ein Listener aus der TraceListenerCollection gelöscht. Die anschließende Meldung wird nur vom verbleibenden Listener weitergeleitet.

Sollten Sie versuchen, den Informationsfluss nur über den Aufruf der Flush-Methode auf die einzelnen Listener zu steuern, werden Sie damit wenig Erfolg haben. Denn solange ein Listener registriert ist, werden alle eingehenden Informationen in seinen Puffer geschrieben und beim nächsten Aufruf von Flush an den Abnehmer weitergeleitet.

Die Klasse »EventLogTraceListener«

Alternativ zum TextWriterTraceListener können Sie mit einer Instanz der Klasse EventLogTraceListener Meldungen in das Windows-Ereignisprotokoll schreiben. Auch dieser Listener muss in der Listeners-Auflistung mit der Add-Methode registriert werden. Das Verhalten hinsichtlich der Pufferung der Meldungen ist identisch mit der, die wir im letzten Abschnitt erörtert haben.

Die Klasse EventLogTraceListener stellt drei Konstruktoren bereit:

Rufen Sie den parameterlosen Konstruktor auf, müssen alle Eigenschaften konfiguriert werden, bevor Nachrichten an ein Ereignisprotokoll gesendet werden können. Geeigneter erscheint daher der Konstruktor, der eine Zeichenfolge erwartet, die das Ereignisprotokoll namentlich beschreibt. Diagnosemeldungen, die von den Klassen Debug oder Trace geschrieben werden, werden Sie anschließend im Anwendungsprotokoll von Windows wiederfinden.

Mit der dritten Überladung besteht die Möglichkeit, eine Ablaufverfolgungs- oder Debug-Meldung an ein beliebiges Ereignisprotokoll auf der lokalen oder einer anderen Maschine weiterzuleiten. Darüber hinaus können Sie auch ein benutzerdefiniertes Ereignisprotokoll erstellen. Der Konstruktor erwartet dann die Referenz auf ein EventLog-Objekt, mit dem ein Ereignisprotokoll von Windows beschrieben wird.

Im folgenden Codefragment wird ein Ereignisprotokoll namens MyProtocol auf der lokalen Maschine eingerichtet. Die lokale Maschine wird durch eine Zeichenfolge, die nur einen Punkt enthält, beschrieben. Sie könnten aber auch den Namen eines entfernten Rechners angeben.

Mit der Eigenschaft Source geben Sie einen Bezeichner für die Ereignisquelle an. Innerhalb der Ereignisprotokolle von Windows muss dieser eindeutig sein.

Wollen Sie in Erfahrung bringen, welche Ereignisprotokolle auf der lokalen Maschine eingerichtet sind, können Sie sich über den Aufruf der statischen Methode GetEventLogs der Klasse EventLog ein Array gleichen Typs besorgen und auf jedem Element die Log-Eigenschaft auswerten, die den Namen des Ereignisprotokolls als Zeichenfolge liefert.

Sind keine benutzerdefinierten Ereignisprotokolle in der Registrierungsdatenbank eingetragen, sollte die Ausgabe Application, System und Security lauten.

Grundsätzlich sollten Sie sich darüber bewusst sein, dass das Ereignisprotokoll nicht dazu dient, eine große Anzahl allgemeiner Meldungen vorzuhalten. Beschränken Sie daher den Einsatz des EventLogTraceListeners auf wirklich wichtige Meldungen.

9.2.5 Steuerung der Protokollierung mit Schaltern 

Ausgaben, die mit den Write-Methoden der Klassen Debug und Trace erzeugt werden, suchen sich grundsätzlich immer ihre Abnehmer in den registrierten Listenern. Das .NET Framework stellt Ihnen darüber hinaus mit zwei Schalterklassen einen weiteren effektiven Mechanismus zur Verfügung, mit dem Ablaufverfolgungs- und Debug-Ausgaben dynamisch gesteuert werden können. Bei den Schalterklassen handelt es sich um BooleanSwitch und TraceSwitch, die beide in Switch eine gemeinsame Basisklasse haben.

Die Klasse »BooleanSwitch«

Die einfachere Schalterklasse ist BooleanSwitch, die einem An-/Ausschalter ähnelt. Mit einer Instanz dieser Klasse lassen sich alle Ablaufverfolgungs- und Debug-Ausgaben gemeinsam aktivieren oder deaktivieren.

Die Klasse hat nur einen Konstruktor, dem Sie den Namen des Schalters und eine Beschreibung übergeben müssen:

Standardmäßig sind alle Ausgaben zunächst deaktiviert. Sollen die Ausgaben an die Listener weitergeleitet werden, müssen Sie die Eigenschaft Enabled des BooleanSwitch-Objekts auf True setzen:

Um die aktuelle Schalterstellung auszuwerten und den weiteren Protokollierungsablauf zu steuern, bieten sich die beiden Methoden WriteIf und WriteLineIf der Klassen Debug und Trace an, z.  B.:

Nur dann, wenn der Schalter mit Enabled=True aktiviert ist, wird die Meldung mit genauer Datums- und Zeitangabe an alle registrierten Listener geschickt.

Die Schalterstellung in einer Konfigurationsdatei festlegen

Damit sind aber noch nicht alle Möglichkeiten erschöpft. .NET-Anwendungen können um eine optionale Anwendungskonfigurationsdatei erweitert werden, in der nach Bedarf Einstellungen verändert werden können, ohne dass die Anwendung neu kompiliert werden muss. Anwendungskonfigurationsdateien sind XML-Dateien und immer im Stammverzeichnis der Anwendung zu finden. Der Name einer Konfigurationsdatei setzt sich aus dem Namen der Anwendungsdatei und dem Suffix .config zusammen. Lautet die Anwendungsdatei MyApplication.exe, heißt die Konfigurationsdatei demnach MyApplication.exe.config.

Mit den Vorgaben in einer Konfigurationsdatei können Sie jederzeit das Laufzeitverhalten einer Anwendung beeinflussen und steuern, denn eine Konfigurationsdatei wird vor dem Start einer Anwendung ausgewertet – vorausgesetzt, der Anwendung wurde eine Konfigurationsdatei zugeordnet.

Um eine Anwendungskonfigurationsdatei hinzuzufügen, öffnen Sie im Projektmappen-Explorer das Kontextmenü des Projekts und wählen Hinzufügen Neues Element... In der Liste markieren Sie Anwendungskonfigurationsdatei. Nach der Bestätigung wird die neue Komponente der Anwendung mit dem Dateinamen App.config hinzugefügt und im Codeeditor geöffnet. Nachfolgend sehen Sie die vom Visual Studio bereitgestellte Struktur, die bereits die für die Steuerung der Protokollierung mittels Schalter wichtigsten XML-Elemente enthält. Der besseren Übersicht wegen habe ich allerdings auf die ansonsten auch noch vorhandenen Kommentare verzichtet.

In der Anwendungskonfigurationsdatei werden nicht nur die Schalterstellungen angegeben, sondern darüber hinaus kann das Laufzeitverhalten der gesamten Anwendung maßgeblich beeinflusst werden. In Kapitel 27 werden Sie noch weitere Details zu den Konfigurationsdateien erfahren.

Anstatt ein BooleanSwitch-Objekt mit einer Anweisung im Code zu aktivieren bzw. zu deaktivieren, lässt sich das Verhalten des Schalters in der Anwendungskonfigurationsdatei festlegen. Dazu müssen Sie diese folgendermaßen ändern bzw. ergänzen:

Innerhalb des switches-Knotens wird mit dem add-Element der entsprechende Schalter festgelegt. Eine Konfigurationsdatei ist nicht nur auf die Steuerung eines Schalters beschränkt. Wollen Sie die Ausgabe über mehrere Schalter steuern, fügen Sie einfach für jeden Schalter ein weiteres add-Element hinzu. Das Attribut name gibt den Namen des Schalters an, das Attribut value die Schalterstellung. Dabei steht 1 für die Aktivierung und 0 für die Deaktivierung des Schalters.

In unserem Beispiel ist der Schalter aktiviert. Deshalb wird die Anwendung auch alle Ausgabemeldungen an die registrierten Listener weiterleiten. Wollen wir die Ausgabemeldungen nicht mehr protokollieren, brauchen wir die Konfigurationsdatei nur mit dem Editor zu öffnen und value auf den Wert 0 zu setzen. Beim nächsten Start der Anwendung ist damit die Protokollierung abgeschaltet.

Beachten Sie, dass die Angabe der Schalterstellung im Programmcode dazu führt, dass die Vorgaben in der Konfigurationsdatei verworfen werden.

Die Klasse »TraceSwitch«

Im Gegensatz zu einem BooleanSwitch-Objekt, das nur die Einstellungen aktiviert und deaktiviert zulässt, können die Ablaufverfolgungs- und Debug-Ausgaben mit einem TraceSwitch-Objekt über die Festlegung mehrerer Ebenen gesteuert werden. Verantwortlich für die Steuerung der Ablaufverfolgung ist die Eigenschaft Level, die vom Typ der Enumeration TraceLevel ist.

In TraceLevel werden Ablaufverfolgungsebenen definiert, die Sie der folgenden Tabelle entnehmen können.

Wollen Sie ein TraceSwitch-Objekt erzeugen, müssen Sie dem Konstruktor den Namen des Schalters und eine Beschreibung übergeben. Damit gleicht die Instanziierung der von BooleanSwitch. Um die Ablaufverfolgungsebene festzulegen, weisen Sie der Eigenschaft Level einen Wert zu, z.  B.:

Damit in Abhängigkeit von der Ablaufverfolgungsebene mit den Methoden WriteIf und WriteLineIf ein boolescher Wert ausgewertet werden kann, sind in der Klasse TraceSwitch die Eigenschaften

TraceError

TraceWarning

TraceInfo

TraceVerbose

definiert, die je nach Schalterstellung True oder False zurückgeben. Um die Ausgabe der Meldungen zu steuern, müssen Sie in den Methoden WriteIf oder WriteLineIf nur eine der Eigenschaften überprüfen:

Die Einstellung der Eigenschaften Level umfasst gleichzeitig auch die niedriger bewerteten Einstellungen, ausschließlich TraceLevel.Off. Wenn im Code beispielsweise die Ablaufverfolgungsebene auf TraceLevel.Info festgelegt ist, bedeutet dies, dass die Eigenschaften TraceError, TraceWarning und TraceInfo True liefern, während TraceVerbose False ist.

Zur Steuerung des oder der TraceSwitch-Objekte bietet sich ebenfalls die Anwendungskonfigurationsdatei an. Dem Attribut value müssen Sie für eine bestimmte Ablaufverfolgungs- ebene einen zugeordneten Wert übergeben. Sie können diesen der Tabelle 9.4 entnehmen. Die folgende Konfigurationsdatei beschreibt die Einstellung TraceLevel.Info.

9.2.6 Bedingte Kompilierung 

Die bedingte Kompilierung ermöglicht es, Codeabschnitte oder Methoden nur dann zu kompilieren, wenn ein bestimmtes Symbol definiert ist. Üblicherweise werden bedingte Codeabschnitte dazu benutzt, während der Entwicklungsphase den Zustand der Anwendung zur Laufzeit zu testen. Bevor ein Release-Build der Anwendung erstellt wird, wird das Symbol entfernt. Die Abschnitte, deren Code als bedingt kompilierbar gekennzeichnet ist, werden dann nicht mitkompiliert.

Der folgende Code zeigt ein Beispiel für bedingte Kompilierung:

Mit der Prägprozessordirektiven #dConst wird das Symbol TEST definiert und diesem der Wert 10 zugewiesen. Symbole werden immer vor der ersten Anweisung, die selbst keine #Const-Direktive ist, festgelegt. Eine so beschrieben Direktive gilt nur in der Quellcodedatei, in der sie definiert ist.

Mit #If, #ElseIf oder #Else wird der Wert oder das Vorhandensein des angegebenen Symbols getestet. Stimmt die Bedingung mit der Festlegung des Symbols überein, liefert die Prüfung das Ergebnis True, und der Code wird ausgeführt. Da im Beispielcode das Symbol TEST mit dem Wert 10 definiert ist, wird die Ausgabe lauten:

Standardmäßig sind in VB-Projekten die beiden Symbole DEBUG und TRACE vordefiniert. Diese Vorgabe ist im Projekteigenschaftsfenster eingetragen und hat anwendungsweite Gültigkeit. Die Symbole beschreiben durch ihre Existenz den booleschen Wert True. Sie können sie löschen oder auch weitere hinzufügen. Öffnen Sie dazu das Eigenschaftsfenster des Projekts, markieren Sie die Lasche Kompilieren, und klicken Sie auf die Schaltfläche Erweiterte Kompilierungsfunktion. Es öffnet sich ein Dialog wie in Abbildung 9.6 gezeigt.

Hier klicken, um das Bild zu Vergrößern

Abbildung 9.6     Dialog zur Festlegung der Symbole der bedingten Kompilierung

Das Projekteigenschaftsfenster bietet darüber hinaus den Vorteil, dass sich die Symbole einer bestimmten Build-Konfiguration zuordnen lassen. Wählen Sie in der Drop-down-Liste der Karte Kompilieren im Eigenschaftsfenster Konfiguration die Build-Konfiguration aus, für welche die angegebenen Symbole gültig sein sollen. Wenn Sie beispielsweise keine Direktiven im Code angeben, dafür aber der Debug-Konfiguration das Symbol TEST zugeordnet haben, wird der in #If – #End If eingeschlossene Code im Debug-Build mitkompiliert, im Release-Build jedoch nicht. Die im Projekteigenschaftsfenster definierten Direktiven gelten projektweit.